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Abstract 


This memo describes the full set of notations needed to represent a 
text string in a Dial Sequence. A Dial Sequence is normally composed 
of Dual Tone Multi Frequency (DTMF) elements, plus separators and 
additional "actions" (such as "wait for dialtone", "pause for N 
secs", etc.) which could be needed to successfully establish the 
connection with the target service: this includes the cases where 
subaddresses or DTMF menu navigation apply. 


1. Introduction 


Since the very first devices interacting with GSTN services appeared, 
a need for a unique text string representation of commonly called 
telephone numbers, and more generally DTMF sequences and actions, was 
foreseen. 


This memo describes the full text string representation method. This 
specification was explicitly created to provide an easy, unique and 
complete reference which MUST be used by all other specifications 
needing a text string representation for a Dial Sequence. 


The specification was collected directly from Dial Sequence 
definitions which are already described in existing Standard Track 
specifications (such as [6] [7] [8] [9]), and is fully synchronized 
with them. Full compatibility is thus assured, and as a consequence, 
this specification results in a compendium of existing definitions. 
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This notation is a fully compatible compendium of existing notations, 
and should be used in all specifications needing a text string 
representation of a Dial Sequence. 


Although the commonly called "telephone numbers" are normally used to 
generate a Dial Sequence when establishing a connection, the full 
abstract E.164 addresses [2], i.e., the universal addressing on the 
Global Switched Telephone Network (GSTN), have further elements which 
cannot be dialled. Thus abstract E.164 addresses cannot be fully 
converted into a Dial Sequence or fully represented using this 
notation. 


1.1. Terminology and Syntax conventions 


In this document the formal definitions are described using ABNF 
syntax, as defined in [3]. This memo also uses some of the "CORE 
DEFINITIONS" defined in "APPENDIX A - CORE" of that document. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 [4]. 


The following terms are also defined in this document: 


Dial Sequence: 
a series of DTMF elements and human or device "actions"; 


phone-string: 
a text representation of a Dial Sequence; 


GSTN address: a commonly called "telephone number" on the GSTN, 
i.e., a diallable subset of an E.164 abstract address or any 
private numbering schema diallable address; 


gstn-phone: 
a text representation of a GSTN address; 


subaddr-string: 
a text representation of a GSTN subaddress (which includes ISDN 


subaddresses [2] and T.33 subaddresses [5]); 


post-dial: 
a text representation of a post dialling sequence. 
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2. The "Dial Sequence" definition 


The possible elements composing a Dial Sequence can vary from a 
minimum number, up to a really large and complex collection: in fact, 
the sequences already needed to dial a gstn-phone, which is a subset 
of the generic Dial Sequence, well represents this variety and 
complexity of cases. 


In particular, a Dial Sequence is composed by: 


- "DTMF elements": normally available as "keys" on numeric keypads 
of dialling devices; 


- "actions": normally performed by the agent (human or device) 
composing the Dial Sequence; 


- "separators": used only to improve human readability of a Dial 
Sequence. 


2.1. The "phone-string" definition 


The text representation of the Dial Sequence elements is defined in 
the phone-string specification: 


phone-string = 1*( DTMF / pause / tonewait / written-sep ) 


DTMF = ( DIGIT / "yn / wee / "a" / "R" / wo / "D" ) 
; special DTMF codes like "*", "#", "A", "B", 
; "C", "D" are defined in [1]. 
; Important Note: these elements only apply for 
; alphabetic strings used in DTMF operations. 
; They are NOT applicable for the alphabetic 
; characters that are mapped to digits on phone 
; keypads in some countries. 


pause = "p" 

tonewait = "w" 

written-sep = ( "=" / "." ) 
Note: 


DTMF are the "DTMF elements", pause and tonewait are the "actions" 
and written-sep are the "separators". 


The "pause" and "tonewait" elements interpretation of the phone- 


string depends on the specific devices and implementation using the 
specification. Thus their exact meaning is not mandated in this 
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document. The next section provides some examples drawn from common 
practice. Both "pause" and "tonewait" are case insensitive. 


Implementation of "pause" and "tonewait": 


- one instance of a "pause" SHOULD be interpreted as a pause of 
one second between the preceding and succeeding dial string 
elements; 


- a "tonewait" SHOULD be interpreted as a pause that will last 
until the calling party hears a dial tone or another indication 
that more dial string characters may be processed. An off-hook 
indication MAY also be interpreted as this kind of indication 
(meaning that the audio channel has been opened to the 
receiving party); 


- because these characters are not a part of the GSTN subscriber 
address (telephone number) per se, any dial string characters 
that succeed either a "pause" or "tonewait" SHOULD be sent 
using DTMF signalling. 


The use of written-sep elements is allowed in order to improve human 
readability of the phone-string. The written-sep are elements which 
can be placed between dial elements, such as digits etc. Any 
occurrences of written-sep elements in a phone-string MUST NOT result 
in any action. Conformant implementations MAY drop or insert 
written-sep into the phone-string they handle. 


The phone-string definition is used in the following sections to 
explicitly describe the encoding of some specific subcases where it 
applies. 


3. The "gstn-phone" definition 


In order to access a GSTN address, a human or a device must perform a 
Dial Sequence. Thus, a GSTN address can be represented using the 
phone-string elements. In particular, diallable E.164 numeric 
addresses [2] represent a limited subset of all possible GSTN 
addresses, while the complete complex case needs a full encoding 
schema, as it also includes a local or private addressing schema. 


In order to describe this distinction and provide anyhow a complete 
encoding schema, the following definition of "gstn-phone" is 
provided: 


gstn-phone = ( global-phone / local-phone ) 
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3.1. The "global-phone" definition 


The purpose of the global-phone element is to represent diallable 
E.164 numeric addresses. As such, it uses a subset of a phone-string 
definition only. 


The syntax for a global-phone element is as follows: 
global-phone = "+" 1*( DIGIT / written-sep ) 


Any other dialling schemes MUST NOT use the leading "+" defined here. 
The "+" sign is strictly reserved for the standard "global-phone" 
syntax, and, even if not specifically part of the phone-string 
definition, it is needed to uniquely label a global-phone. 


3.2. The "local-phone" definition 


The local-phone element is intended to represent the set of possible 
cases where the global-phone numbering schema does not apply. Given 
the different and complex conventions currently being used in the 
GSTN system, the local-phone definition supports a large number of 
elements. 


The detailed syntax for local-phone elements is as follows: 
local-phone = [ exit-code ] dial-number 
local-phone =/ exit-code [ dial-number ] 


exit-code = phone-string 
; this will include elements such as the digit to 
; access outside line, the long distance carrier 
; access code, the access password to the service, 
7; etc... 


dial-number = phone-string 
; this is in many cases composed of different elements 
7 such as the local phone number, the area code 
; (if needed), the international country code 
; (if needed), etc... 


Notes: 
The "+" character is reserved for use in a global-phone and MUST 
NOT be used in a local-phone string; 


Please note that a local-phone string MUST NOT be a null string, 


i.e., at least an exit-code, or a dial-number or both MUST be 
present. 
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4. The "“subaddr-string" definition 


In GSTN service, there are cases where a subaddress is required to 
specify the final destination. To specify these subaddresses, a Dial 
Sequence is also used, and thus the "subaddr-string" can be encoded 
as: 


subaddr-string = phone-string 


Note: 
Within actual uses of subaddresses, some specific services can 
limit the possible set of phone-string elements allowed. In 
particular, there are ISDN subaddresses [2] [8], which restrict 
the phone-string elements to 1*( DIGIT / written-sep ) and service 
specific subaddresses, like the fax service T.33 subaddress [5] 
[7], which restrict phone-string elements to 1%*( DIGIT ). 


5. The "post-dial" definition 
In some cases, after the connection with the destination GSTN device 
has been established, a further dialling sequence is required to 
access further services. A typical example is an automated menu- 
driven service using DTMF sequences. These cases may be represented 
using the "post-dial" definition below: 

post-dial = phone-string 

6. Examples 
In order to clarify the specification we present, here are a limited 
set of examples. Please note that all the examples are for 


illustration purposes only. 


A GSTN address in Italy, dialled from U.S.A., using local-phone, 
without written-sep: 


01139040226338 
A GSTN address in Germany, using global-phone and written-sep ".": 
+49.81.7856345 


A GSTN address in U.S.A. using global-phone and written-sep "-": 


+1-202-455-7622 
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A post-dial sequence, pausing, dialling 1, waiting for dial tone, 
dialling 7005393, waiting again for dial tone and dialling 373; note 
the use of four "p" elements (pppp) to specify a longer initial 
pause: 


pppp1w7005393w373 


A Dial Sequence in Italy (long distance call), using local-phone, 
with exit-code "9", long distance access "0", area code "40", pause 
"p" and written-sep ".": 


9p040p22.63.38 


A Dial Sequence using exit-code "0", a wait for dial tone, local- 
phone for an International "800" toll-free number dialled from 
Belgium (international prefix "00"), and a post-dial sequence to 
access a voice mailbox with userID "334422" and Personal 
Identification Number (PIN) code "1234": 


0w00800-39380023pp334422p1234 
7. Conclusions 


This proposal creates a full standard text encoding for Dial 
Sequences, including GSTN and diallable E.164 addresses, and thus 
provides a unique common representation method both for standard 
protocols and applications. 


Some definitions, like these corresponding to an alias of the generic 
phone-string element, are somewhat a theoretical distinction; however 
they are useful to provide a more subtle distinction, allowing other 
specifications to be more exact in a consistent way. 


The proposal is consistent with existing standard specifications. 
8. Security Considerations 


This document specifies a means to represent Dial Sequences, which 
could include GSTN addresses and private codes sequences, like 
Personal Identification Numbers, to access special services. As 
these text strings could be transmitted without encoding inside 
protocols or applications services, this could allow unauthorized 
people to gain access to these codes. Users SHOULD be provided 
methods to prevent this disclosure, like code encryption, or 
masquerading techniques: out-of-band communication of authorization 
information or use of encrypted data in special fields are the 
available non-standard techniques. 
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9. Collected ABNF Syntax 


In this section we provide a summary of ABNF specifications. 


phone-string = 1*( DTMF / pause / tonewait / written-sep ) 
DIMF = ( DIGIT / "#" / TET / MAN / MBM SMM / UHM ) 
written-sep = ( "=" / ™.™ ) 

pause = "p" 

tonewait = "w" 

gstn-phone = ( global-phone / local-phone ) 

global-phone = "+" 1*( DIGIT / written-sep ) 

local-phone = [ exit-code ] dial-number 


local-phone =/ exit-code [ dial-number ] 
exit-code = phone-string 
dial-number = phone-string 
subaddr-string = phone-string 
post-dial = phone-string 
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12. Full Copyright Statement 
Copyright (C) The Internet Society (2003). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assignees. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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